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1.  Introduction 

Object-oriented  programming  languages  such  as  CommonLoops  [l],  SmallTalk 
[2]  and  Flavors  [3]  all  involve  the  notions  of  class  and  object.  A  given  object  can  be 
“in”  a  class  C  and  thus  “inherit”  information  attached  to  C.  In  this  paper  we  view 
classes  as  predicates;  if  an  object  x  is  in  a  class  C  then  we  say  that  C  is  true  of  x;  if  x 
is  not  in  C  then  we  say  that  C  is  false  of  x.  In  Flavors  and  in  CommonLoops  a  class 
C  is  true  of  x  just  in  case  the  expression  (typep  x  C)  returns  T.  Unlike  ordinary 
lambda  predicates,  however,  the  classes  of  object-oriented  programming  languages 
have  a  (compile  time)  computable  inheritance  relation.  Given  any  two  classes  C\ 
and  C2  there  is  a  uniform  way  to  determine  if  Ci  inherits  from  C2.  Object-oriented 
programs  specify  behavior  in  terms  of  classes.  A  behavioral  specification,  such 
as  how  an  object  should  respond  to  a  message,  is  associated  with  (“governs”)  a 
particular  class  C.  If  C  is  true  of  an  object  x  then  the  specifications  associated  with 
C  apply  to  X. 

We  wish  to  extend  the  notion  of  class  so  that  any  Boolean  combination  of  classes 
is  also  a  class.  Boolean  classes  allow  greater  precision  and  conciseness  in  naming 
the  class  of  objects  governed  by  a  particular  specification.  For  example,  consider 
a  battlefield  video-game  with  the  classes  TARGET  and  PROJECTILE  where  targets 
are  things  like  tanks,  ships  and  planes  while  projectiles  are  things  like  missiles, 
torpedoes,  or  cannon  shells.  Suppose  that  the  game  also  has  the  claisses  LAND- 
OBJECT,  AIR-OBJECT  and  SEA-OBJECT.  Now  consider  a  particular  procedure  for 
displaying  the  explosion  of  a  surface  target,  i.e.  a  target  which  is  not  an  air  object. 
The  class  governed  by  the  explosion  display  procedure  can  be  written  as 

(:and  TARGET  (mot  AIR- OBJECT)) 

The  above  class  need  not  be  mentioned  in  any  user  defined  inheritance  relationships. 
Boolean  classes  (and  the  associated  specifications)  are  automatically  placed  at  the 
appropriate  location  in  the  inheritance  hierarchy. 

1.1  Boolean  Classes  vs.  Simple  Multiple  Inheritance 

Boolean  classes  make  it  easier  to  specify  and  maintain  inheritance  hierarchies. 
In  a  certain  sense  any  object-oriented  language  with  multiple  inheritance  can  sim¬ 
ulate  Boolean  cl2isses;  any  inheritance  hierarchy  involving  Boolean  claisses  can  be 
expressed  as  a  hierarchy  among  non-Boolean  classes  (see  below).  With  Boolean 
classes  however  the  construction  of  this  inheritance  hierarchy  can  be  largely  auto¬ 
mated  and  the  hierarchy  can  be  automatically  updated  in  non-trivial  ways  when 
new  classes  are  introduced  and  when  new  inheritance  relations  are  given  by  the 
user. 


Boolean  classes  can  be  simulated  in  any  system  with  multiple  inheritance  by 
manually  installing  the  appropriate  inheritance  relations.  For  example  consider  the 
Boolean  class  (:or  Ci  C2).  This  class  corresponds  to  the  set  of  all  things  which  are 
either  in  class  Ci  or  in  class  C2.  The  Boolean  class  (:or  Cj  C2)  can  be  simulated 
with  a  “primitive”  class  0R-C1-C2  where  the  user  specifies  that  both  C\  and  C2 
inherit  from  the  class  0R-C1-C2.  Once  this  is  done  any  class  which  inherits  from 
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either  Ci  or  will  necessarily  inherit  from  0R-C1-C2.  Similarly,  consider  the  class 
(:and  C\  C2)  which  corresponds  to  the  set  of  all  things  which  are  in  both  the  class 
Cl  and  the  class  C2.  This  class  can  be  simulated  with  a  primitive  class  AND-C1-C2 
where  for  each  class  C3  that  inherits  from  both  Ci  and  C2  the  user  specifies  that 
C3  also  inherits  from  AND-C1-C2. 

Note  that  simulating  the  class  (;and  Ci  C2)  requires  the  user  to  know  about  all 
classes  that  inherit  from  both  Ci  and  C2.  This  is  an  unreasonable  requirement  for 
large  systems  where  different  classes  are  constructed  at  different  times  by  different 
users.  With  genuine  Boolean  classes  the  inheritance  relationships  for  the  class 
(:and  Ci  C2)  are  constructed  automatically  by  the  system  so  the  user  need  not 
know  all  the  classes  that  inherit  from  both  Ci  and  C2. 

1.2  Technical  Difficulties 

There  are  two  technical  difficulties  involving  Boolean  classes:  the  uninstantiable 
class  problem  and  the  modularity  breakdown  problem.  The  uninstantiable  class 
problem  involves  classes  which  are  inherently  uninstantiable.  For  example  the  class 
(:or  Cl  C2)  cannot  be  directly  instantiated;  as  we  shall  see,  if  x  is  created  by 
instantiating  (:or  Ci  C2)  it  is  not  appropriate  for  i  to  be  a  member  of  Ci.  Neither  is 
it  appropriate  for  a:  to  be  a  member  of  C2.  We  solve  the  uninstantiable  class  problem 
by  identifying  those  classes  which  are  inherently  uninstantiable  and  specifying  that 
any  attempt  to  directly  instantiate  an  uninstantiable  class  should  signal  an  error. 

The  modularity  breakdown  problem  occurs  when  a  class  written  for  one  system 
is  inherited  by  a  class  in  a  totally  unrelated  system.  For  example  consider  the  class 
(:not  C)  which  includes  all  objects  which  are  not  in  class  C.  The  clziss  (:not  C), 
and  any  behavioral  specification  associated  with  it,  will  be  inherited  by  a  totally 
unrelated  class  D.  The  modularity  breakdown  problem  can  be  solved  with  simple 
restrictions  on  inheritance  specifications  and  on  the  cleisses  which  are  allowed  to 
carry  behavioral  specifications. 

This  paper  begins  with  a  formal  specification  for  Boolean  classes.  We  then  give 
an  algorithm  for  constructing  inheritance  relations  and  identifying  uninstantiable 
classes,  and  present  a  rigorous  proof  of  the  correctness  of  this  procedure.  We  also 
formally  prove  that  the  modularity  breakdown  problem  is  solved  via  certain  simple 
restrictions  on  the  inheritance  hierarchy  and  on  the  classes  which  are  allowed  to 
carry  behavioral  specifications.  We  do  not  discuss  the  nature  of  behavioral  spec¬ 
ifications  or  the  way  that  specifications  are  combined  when  several  specifications 
apply  to  the  same  object. 

2.  Formal  Specification 

We  assume  that  classes  are  named  with  class  expressions  where  a  class  expres¬ 
sion  is  either  a  class  symbol  or  a  Boolean  combination  of  other  class  expressions. 

Definition:  A  class  expression  is  either  a  class  symbol  or  an  expression  of  the 

form  (:not  E),  (:or  Ei  or  (rand  Ei  ...En)  where  E,  Ex,  ...En  are 
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other  class  expressions.  A  literal  is  either  a  class  symbol  C  or  the  negation  of 
a  class  symbol,  i.e.  (:not  C). 

We  view  classes  as  predicates:  given  a  class  C  and  an  object  i,  if  x  is  in  the 
class  C  then  we  say  that  C  is  true  of  x  and  if  x  is  not  in  C  then  we  say  that  C 
is  false  of  x.  Boolean  class  expressions  are  interpreted  as  predicates  in  the  obvi¬ 
ous  way:  the  class  expression  (mot  E)  is  true  of  an  object  x  just  in  case  E  is 
false  of  X]  (:or  Ei  E2  ■  ■  ■  En)  is  true  of  x  just  in  case  some  E,  is  true  of  i,  and 
(:and  Ei  E2  ■  ■  ■  En)  is  true  of  x  just  in  case  all  of  the  classes  Ei  are  true  of  x. 

In  defining  a  set  of  classes  a  programmer  provides  a  set  of  class  expressions 
and  a  specified  inheritance  hierarchy  for  those  class  expressions.  In  languages  such 
as  Flavors  and  CommonLoops  the  inheritance  hierarchy  is  specified  by  associating 
each  c'ass  with  a  list  of  “superior”  or  “included”  classes.  For  theoretical  generality 
and  cc-nccptuai  simplicity  we  gcneialize  inheritance  specifications  to  allow  for  an 
arbitr;  ry  set  of  implications  of  a  certain  form. 

Definition:  An  inheritance  specification  is  a  finite  set  of  implicatiors  of  the 
fi  rm  (:iniplios  C  E)  where  C  is  a  class  symbol  and  E  is  any  class  ex])ression. 

Intuitively  an  implication  of  the  form  (limplies  C  E)  says  that  for  any  object  z, 
if  C  is  true  of  x  then  E  should  be  true  of  z,  i.e.  every  instance  of  C  should  be  an 
instance  of  E.  and  thus  that  C  inherits  from  E. 

The  standard  specifications  of  inheritance  relations  can  be  easily  translated  into 
irnplic  i  .ii  I’  -i  of  the  above  form.  More  specifically,  to  state  that  a  class  C  inherits 
irom  t  iie  ‘  co.niponents"  Ci,(.2  ■  •  •  Cn,  one  tises  the  implications 

(:iniplic8  C  Cj) 

(:implios  C  C2) 

(•.implies  C  Cn) 

[■'  ?<  iss  r,'  inherit:  fr<'T!!  '  Ij  C  then  we  say  that  C  is  a  generalization  of 

(■ .  (•  \ » -1  ail  inheritaiu  e  sp.  1  ifi.  ,!l  ion  /  and  a  class  C  we  would  like  to  construct 

llic  S'  1  of  gt'iicrali/ations  of  tlio  rla.ss  i.e.  the  set  of  all  class  symbols  which 
\ 

C  inh  'rits  'rom.'  In  langu.ngos  surfi  a-  Flavors  and  CommonLoops  the  process  of 
conip  i  iii;'  all  of  the  genera'i/ntieuw  of  a  given  class  is  basically  a  transitive  closure 
op(‘ra.i  ion.  one  linds  all  iiniii' diate  generalizations,  the  immediate  generalizations 
of  thow  generalizations,  and  so  on. 

1  n!f ’•tunately  computing  the  set  of  generalizations  of  a  class  is  more  complex 
wh'u  Mor.le-in  expressions  ai"  u.sed  in  the  inheritance  specification.  For  example 
consider  the  following  inheritance  specification: 

(:implies  CT  (:or  Cj  C3)) 

^Foi  nnw  we  consider  only  those  generalizations  which  arc  class  symbols;  Boolean  gen¬ 
eral  7.a(  ions  will  be  discussed  later. 
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(implies  C2  C4) 

(timplies  C3  C4) 

Let  X  be  an  arbitrary  object  such  that  Ci  is  true  of  x.  The  first  implication  says 
that  either  C2  or  C3  is  true  of  x.  In  either  case  the  above  implications  state  that 
C4  must  be  true  of  x.  In  short,  if  Ci  is  true  of  an  object  then  C4  is  true  of  that 
object.  Thus  C4  is  a  generalization  of  Ci. 

An  inheritance  specification  I  can  be  viewed  as  a  set  of  formulas  of  propositional 
logic  where  each  formula  is  true  of  all  objects.  To  compute  the  set  of  generalizations 
of  a  class  C  one  must  examine  the  logical  consequences  of  the  formulas  in  I. 

Definition:  Let  C  be  a  class  symbol  and  let  J?  be  a  class  expression.  We 
say  that  E  is  &  generalization  of  C  under  an  inheritance  specification  /  (or 
that  C  inherits  from  E  under  /)  if  the  expression  (limplies  C  E)  is  a.  logical 
consequence  of  the  conjunction  of  all  the  implications  in  7. 

The  above  definition  treats  the  inheritance  specification  7  as  a  formula  of  Boolean 
logic  (the  conjunction  of  all  the  implications  in  7).  It  is  natural  to  ask  whether 
any  Boolean  formula  could  be  used  ais  an  inheritance  specification.  The  answer  is 
no;  to  avoid  the  modularity  breakdown  problem  we  have  intentionally  restricted 
the  inheritance  hierarchy  to  be  a  set  of  implications  of  a  certain  form.  However  the 
restrictions  on  the  inheritance  hierarchy  are  extremely  weak;  most  Boolean  formulas 
can  be  faithfully  translated  into  a  legal  inheritance  hierarchy  and  there  is  a  simple 
semantic  characterization  of  those  formulas  which  can  be  translated  into  a  legal 
inheritance  specification. 

The  semantic  characterization  of  the  formulas  which  can  be  translated  into 
inheritance  specifications  involves  the  notion  of  a  “lost”  object.  We  say  that  an 
object  X  is  lost  if  every  class  symbol  is  false  of  x.  Note  that  if  7  is  a  legal  inheritance 
specification  and  z  is  a  lost  object  then  z  satisfies  every  implication  in  7;  z  satisfies 
an  implication  of  the  form  (:implies  C  E)  because  the  antecedent  C  is  false  of  z. 
Since  lost  objects  satisfy  every  implication  in  any  inheritance  specification,  every 
inheritance  specification  has  a  model  and  thus  every  inheritance  specification  is 
logically  consistent  (one  can  never  derive  a  contradiction  from  the  formulas  in  an 
inheritance  specification.)  It  turns  out  that  any  Boolean  formula  which  is  satisfied 
by  lost  objects  can  be  translated  into  a  legal  inheritance  specification. 

Lemma  I.  Let  B  be  any  Boolean  expression.  If  B  is  true  of  lost  objects 
then  there  is  an  inheritance  specification  7  such  that  the  conjunction  of  all 
implications  in  7  is  logically  equivalent  to  B. 

Proof:  Suppose  that  B  is  true  of  lost  objects  and  let  E  be  the  conjunctive 
normal  form  of  B.  The  expression  is  a  conjunction  of  disjunctions  of  liter¬ 
als  where  every  disjunction  of  literals.  Note  that  each  disjunction  in  E  must 
contain  at  least  one  negative  literal  because  a  disjunction  which  contains  only 
positive  literals  is  false  on  lost  objects  and  if  E  contained  such  a  disjunction 
then  E  would  be  false  on  lost  objects  violating  the  assumption  that  B  is  true 
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of  lost  objects.  Since  every  disjunction  in  E  contains  a  negative  literal,  ev¬ 
ery  disjunction  can  be  written  as  {:or  (:not  C)  Li  ...Ln)  which  is  logically 
equivalent  to  the  implication  (:iinplies  C  (:or  Li . .  -  Ln))-  (Actually  the  dis¬ 
junctive  clause  might  contain  only  the  single  literal  (:not  C)  in  which  case  it 
is  equivalent  to  the  implication  (:implies  C  (mot  C)).)  Thus  E  is  equivalent 
to  a  conjunction  of  implications  of  the  desired  form. 

The  requirement  that  lost  objects  satisfy  inheritance  specifications  plays  an  impor¬ 
tant  role  in  the  solution  of  the  modularity  breakdown  problem. 

2.1  Mi  king  Instances  of  a  Class 

In  most  object-oriented  programming  languages  objects  are  created  by  “instan¬ 
tiating’’  classes.  If  the  object  x  was  created  by  instantiating  some  class  symbol  C 
then  we  will  call  x  an  instantiation  of  C.  In  this  section  we  only  consider  instan¬ 
tiations  of  class  symbols.  We  do  not  allow  a  class  expression  E  to  be  instantiated 
directly.  Instead,  one  can  construct  the  inheritance  specification  (limplien  C  E) 
for  some  new  class  symbol  C  and  then  one  can  instantiate  C. 

Class  expressions  introduce  some  subtleties  in  instantiation.  In  most  object- 
oriented  languages,  if  x  is  an  instantiation  of  a  class  C  and  E  is  any  other  class  then 
E  is  true  of  x  just  in  case  C  inherits  from  E.  Unfortunately  this  principle  does  not 
hold  when  E  can  be  a  Boolean  class  expression.  In  particular  it  is  possible  for  C 
to  inherit  from  neither  E  nor  (mot  E)  but  clearly  either  E  or  (:not  E)  must  be 
true  of  I.  If  I  is  an  instantiation  of  C  we  must  be  careful  to  specify  exactly  which 
classes  are  true  of  x.  It  suffices  to  specify  the  class  symbols  which  contain  x;  to 
determine  if  a  Boolean  expression  E  is  true  of  x  it  suffices  to  know  whether  or  not 
each  cl  iss  symbol  in  E  is  true  of  x. 

Siiccification:  Let  C  be  a  class  symbol,  I  be  an  inheritance  specification,  and 
let  X  be  an  instantiation  of  C.  For  any  class  symbol  C'  we  specify  that  C'  is 
true  of  X  just  in  case  C"  is  a  generalization  of  C  under  /. 

Nmw  consider  the  case  where  C  does  not  inherit  from  either  the  class  symbol 
C'  or  (:not  C).  If  x  is  an  instantiation  of  C  then  the  above  specification  requires 
that  C  is  false  of  x.  This  implies  that  (mot  C)  is  true  of  x  even  though  (:not  C) 
is  not  a  generalization  of  C. 

2.2  Urinstantiable  Classes 

This  section  formally  defines  the  notion  of  an  uninstantiable  class.  A  proce¬ 
dure  fc  r  identifying  uninstantiable  classes  is  given  in  a  later  section.  A  class  is 
uninst;  ntiable  if  instantiations  of  that  class  would  be  “pathological”.  Any  attempt 
to  instantiate  an  uninstantiable  class  should  generate  an  error. 

Definition:  We  say  that  an  object  x  violates  an  inheritance  implication  (:im- 
pHes  C  E)  if  C  is  true  of  x  but  E  is  false  of  x.  Now  let  I  be  any  inheritance 
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specification  and  let  C  be  an>  class  symbol.  We  say  that  C  is  uninstantiabU 
under  I  if  an  instantiation  i  of  C  would  violate  some  implication  in  I. 


It  is  easy  to  see  how  uninstantiable  classes  arise.  For  example  suppose  that  I 
includes  both  the  implications 


(nmplies  Ci  C2) 


and 


(zimplies  Ci  (:not  C2)) 

Clearly  any  instantiation  of  Ci  would  violate  one  of  these  implications. 


A  more  interesting  example,  mentioned  in  the  introduction,  involves  an  inher¬ 
itance  specification  containing  the  following  single  implication: 

(zimplies  C\  (:or  C2  C3)) 

Under  this  inheritance  specification  neither  C2  nor  C3  is  a  generalization  of  Ci. 
Both  C2  and  Cz  would  be  false  of  an  instantiation  x  of  Ci .  Thus  an  instantiation 
of  Cl  would  violate  the  above  inheritance  specification  which  says  if  Ci  is  true  of  x 
then  either  C2  or  C3  must  be  true  of  x. 


2.3  Inheriting  Methods  and  Instance  Variables 

We  allow  information  to  be  attached  to  any  class  expression.  For  exam¬ 
ple  we  might  define  a  method  that  handles  messages  sent  to  objects  in  the  class 
(:or  Cl  C2).  Similarly  one  might  declare  that  objects  in  a  given  class,  such  as 
(:and  Ci  (mot  C2)),  should  all  have  a  certain  instance  variable.  In  general  we 
will  simply  speak  of  “information”  that  is  inherited  by  objects  in  a  given  class.  We 
assume  that  there  is  a  finite  set  of  information  bearing  cleiss  expressions,  i.e.  class 
expressions  which  either  have  method  definitions  or  instance  variables  associated 
with  them. 

Let  C  be  a  class  symbol  which  is  instantiable  relative  to  an  inheritance  spec¬ 
ification  I.  If  X  is  an  instantiation  of  C  then  the  above  specifications  determine 
the  set  of  information  bearing  class  expressions  which  are  true  of  x.  The  same  set 
of  information  bearing  classes  applies  to  all  instantiations  of  C  so  it  is  possible  to 
build  a  “method  table”  for  the  class  C  which  summarizes  all  the  information  which 
applies  to  instantiations  of  C  (we  are  not  concerned  here  with  how  information  gets 
combined). 

To  solve  the  modularity  breakdown  problem  we  place  a  simple  restriction  on 
the  class  expressions  that  are  allowed  to  carry  information.  Recall  that  an  object  x 
is  called  lost  if  every  class  symbol  C  is  false  of  x. 

Specification:  All  information  bearing  class  expressions  must  be  false  of  lost 

objects,  i.e.  lost  objects  do  not  inherit  any  information. 

For  example  the  class  (:not  AIR-OBJECT)  should  not  carry  information  because 
this  class  is  true  of  lost  objects.  If  the  class  (:not  AIR-OBJECT)  carried  information 
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then  that  information  would  be  inherited  by  classes  in  totally  unrelated  systems; 
one  would  be  faced  with  modularity  breakdown. 

Any  attempt  to  associate  information  with  a  class  expression  that  is  true  of 
lost  objects  should  generate  an  error.  The  following  lemma  establishes  that  the 
above  condition  on  information  bearing  classes  together  with  the  definition  of  a 
legal  itiheritance  specification  solves  the  modularity  breakdown  problem. 

Lemma  II.  Let  I  be  an  inheritance  specification  and  let  Z?  be  a  set  of  infor¬ 
mation  bearing  class  expressions.  If  C  is  a  class  symbol  which  does  not  appear 
ir  either  I  or  D  and  if  x  is  an  instantiation  of  C  then  all  information  bearing 
class  expressions  in  D  are  false  of  x,  i.e.  x  does  not  inherit  any  information 
from  D. 

Proof:  First  we  prove  that  C  is  the  only  class  symbol  that  is  is  true  of  x.  It  is 
sr  fficient  to  show  that  for  every  other  class  symbol  C,  C  is  not  a  generalization 
of  C.  To  show  that  C  is  not  a  generalization  of  C  we  must  show  that  there 
e:  ,ists  a  propositional  model  of  inheritance  specification  I  which  makes  C  true 
and  C  false.  Let  y  be  an  object  such  that  C  is  true  of  y  but  no  other  class 
symbol  is  true  of  y.  In  particular  every  antecedent  of  every  implication  in  /  is 
felse  of  y  so  y  is  a  model  of  1  which  makes  C  true  and  C  false. 

Now  since  C  is  the  only  class  symbol  which  is  true  of  an  instantiation  x  of  C, 
and  since  C  does  not  appear  in  any  information  bearing  class  expression,  an 
information  bearing  class  expression  E  is  true  of  x  just  in  case  E  is  true  of 
lost  objects.  But  since  no  information  bearing  class  is  true  of  lost  objects,  no 
information  bearing  class  is  true  of  x. 

3.  Implementation 

Unfortunately  it  can  be  difficult  to  compute  the  set  of  generalizations  of  a 
given  clas.s  under  a  given  inheritance  specification;  the  algorithm  presented  here 
has  a;  exponential  worst  case  running  time  and  we  cannot  expect  to  find  a  non- 
exponen'ial  procedure.  However  the  procedure  presented  here  is  exponential  in  the 
numb*  r  of  ‘‘complex”  implications  in  the  inheritance  hierarchy  and  in  practice  only 
a  very  small  fraction  of  the  implications  are  complex.  Furthermore  the  procedure  is 
modular;  the  time  required  to  find  all  generalizations  of  a  given  class  is  not  effected 
by  the  presence  of  unrelated  classes  and  inheritance  specifications.  Thus  we  expect 
that  the  exponential  worst  case  behavior  will  not  be  a  problem  in  practice.  First 
we  shf  w  that  the  problem  of  determining  whether  one  class  inherits  from  another 
is  CO-''  P  complete  and  thus  we  cannot  expect  to  find  a  non-exponential  algorithm. 

3.1  Deterinining  Inheritance  is  Co-NP  Complete 

It  is  easy  to  show  that  determining  whether  or  not  a  class  symbol  C  inherits 
from  another  class  C  under  a  specification  I  is  co-NP  complete.  More  specifically 
one  can  reduce  the  problem  of  showing  that  a  set  of  disjunctive  clauses  is  unsatisfi- 
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able  to  the  problem  of  determining  whether  the  implication  (timplies  C  C)  follows 
from  an  inheritance  specification  I.  Given  a  set  ^  of  disjunctive  clauses  let  C,  C 
and  C"  be  symbols  not  occurring  in  B  and  let  I  be  the  inheritance  specification 
containing  the  implication  (:implies  C  (:or  C"  C'))  together  with  all  implications 
of  the  form  (:implies  C"  E)  where  E  is  a  clause  in  B.  We  will  show  that  C' 
follows  from  I  and  C  just  in  case  B  is  unsatisfiable.  If  B  is  unsatisfiable  then  / 
implies  (:not  C")  and  thus  I  and  C  imply  C'.  On  the  other  hand  if  B  is  satisfiable 
then  consider  a  model  of  B  in  which  C"  is  true,  C  is  true,  and  C  is  false.  This 
model  satisfies  all  implications  in  /  while  making  C  true  and  C  false.  Thus  if  B  is 
satisfiable  then  C  does  not  follow  from  I  and  C. 

3.2  Computing  Inheritance 

The  system  of  Boolean  classes  described  here  has  not  yet  been  implemented. 
However  there  is  a  relatively  simple  algorithm  for  determining  whether  a  class  is 
instantiable  and  for  determining  the  set  of  information  bearing  classes  that  are 
generalizations  of  a  given  instantiable  class.  The  first  step  in  this  algorithm  is  to 
convert  the  inheritance  specification  I  into  canonical  form. 

Definition:  An  inheritance  specification  I  is  said  to  be  in  conjunctive  normal 

form  if  every  implication  in  I  has  the  form  (timplies  C  (:or  Li  L2  ...))  where 

each  Li  is  a  literal. 

We  allow  the  disjunction  in  the  consequent  of  an  implication  to  contain  only  a 
single  literal,  in  which  case  the  implication  can  be  written  as  (rimplies  C  L).  Any 
inheritance  specification  I  can  be  converted  to  an  expression  in  conjunctive  normal 
form.  To  see  this  recall  that  an  inheritance  specification  /  consists  of  implications 
of  the  form  (:implies  C  E)  where  C  is  a  class  symbol  and  J?  is  a  class  expression. 
The  class  expression  E  can  be  written  in  conjunctive  normal  form,  i.e.  E  can  be 
written  as: 

(:and  (;or  Li,i  ...  Li,n)  (:or  Lj,!  ...//2,n)  •••) 

The  implication  (limplies  C  E)  can  then  be  written  as  a  set  of  implications  of  the 
form 

(:implies  C  (:or  Ly,i  ... 

Of  course  converting  an  expression  to  conjunctive  normal  form  requires  an 
exponential  amount  of  work  in  general.  However  it  seems  unlikely  that  this  would 
be  a  problem  in  practice;  the  Boolean  expressions  involved  should  usually  be  given 
in  conjunctive  normal  form  anyway. 

Given  an  inheritance  specification  /  we  are  now  interested  in  determining  which 
class  symbols  are  instantiable,  and  for  each  instantiable  symbol  C  we  are  interested 
in  determining  the  set  of  class  symbols  which  generalize  C.  To  do  this  we  assume 
that  the  inheritance  specification  I  has  been  converted  to  conjunctive  normal  form. 
Implications  of  the  form  (:implies  C  L)  will  be  called  simple  while  implications 
of  the  form  (:implies  C  (:or  Lj  L2..-Ln))  (for  n  >  1)  will  be  called  complex. 
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Currrn'  object-oriented  programming  languages  only  allow  for  simple  inheritance 
implications  and  these  are  indeed  the  easiest  to  process. 

D<‘firiition:  Let  T  be  any  set  of  literals  and  let  I  be  an  inheritance  specification 
in  conjunctive  normal  form.  The  simple  closure  of  T  with  respect  to  I  is  the 
lei'St  set  of  litorals  T'  containing  T  such  that  if  C  is  a  class  symbol  in  T'  and 
(:i:ijplios  C  /,)  is  a  simple  implication  in  /,  then  L  is  in  T'. 

To  compute  the  simple  closure  of  a  set  of  literals  T  it  is  sufficient  to  compute 
the  transitive  closure  of  the  directed  graph  given  by  the  simple  implications  in  7. 
Th('  (b  -.ai'-  of  this  computation  are  left  to  the  reader.  Now  let  C  be  a  class  symbol. 
Clearl\  ever)  litei,\i  in  the  sim;  ie  closure  of  the  singleton  set  (C}  is  provalde  from 
C  and  '  However,  since  I  may  :  ontain  complex  implications  there  may  be  symbols 
whicli  :(^llOv,■  tvom  C  and  /  but  which  are  not  in  the  simple  closure  of  {C}.  To  find 
all  syii  lu,l-  winch  follow  from  (,'  vve  must  enumerate  models  of  C.  A  symbol  C 
follo'.v;  from  ('  just  in  case  C  is  true  in  every  model  A/  of  7  such  that  C  is  true  in 
M. 

A  ti.odel  of  propo-sitional  fo;m:i!as  (expressions)  is  usually  taken  to  be  a  truth 
function  which  maps  each  symbol  to  either  true  or  false.  However,  rather  than 
introduce  truth  functions  on  class  symbols,  we  will  represent  a  model  by  a  set  M 
of  clas'  symbols;  members  of  .^7  are  considered  to  be  true  while  class  symbols  not 
in  M  ?. rc  taken  to  be  false. 

Definition:  Let  M  be  a  set  of  class  symbols.  We  say  that  a  literal  L  is  true 
ui.dcr  M  if  either  L  is  a  symbol  in  M  or  L  is  of  the  form  (:not  C)  where 
('  is  not  in  M .  Lot  7  be  an  inheritance  specification  in  conjunctive  normal 
fo  m.  The  set  A/  is  called  a  model  of  I  if  for  every  implication  of  the  form 
(•.implies  C  (:or  Lt  1. 2  . .  .  !.„)).  if  C  is  in  A7  then  one  of  the  literals  L,  is  true 
in  .\f. 

A  syiuuc!  C  inherits  from  a  symbol  C  just  in  case  the  implication  (rimplies  C  C) 
is  pio  abie  from  I.  Hut  (rimplies  C  C')  is  provable  from  I  just  in  case  every 
modf  l  of  1  which  contains  t;  also  contains  C'.  More  specifically,  the  intersection 
of  all  models  of  7  which  contain  yields  the  set  of  all  class  symbols  which  are 
genera  ization^  of  (’.  The  following  procedure  enumerates  models  /  which  contain 
C. 

The  procedure  takes  one  exi)!icit  argument  T  which  is  a  set  of  literals.  The 
procedure  also  makes  use  of  the  inheritance  specification  7.  We  will  show  that  a 
class  symbol  C  is  a  generalizations  of  C  under  7  just  in  C2ise  C'  is  a  member  of 
every  model  returned  by  the  following  function  when  applied  to  the  singleton  set 

Function:  All-Models(T)  takes  a  set  of  literals  and  produces  a  set  of  models. 

1.  [Initialization]  Let  T'  be  the  simple  closure  of  T  with  respect  to  7. 
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2.  [Detect  inconsistency]  If  T'  is  inconsistent,  i.e.  if  there  is  some  symbol  C  in 
T'  such  that  (mot  C)  is  also  in  T,  then  return  the  empty  set  (there  are  no 
models  of  T). 

3.  [Choose  complex  implication]  Let 

(implies  C  (:or  Li  Li  ...Ln)) 

be  a  complex  implication  in  I  such  that  C  is  in  T’  but  none  of  the  literals 
Li,L2,  ...Ln  are  in  T'.  If  there  is  no  such  implication  in  I  then  return  {M} 
where  M  is  the  set  of  class  symbols  in  T'. 


4.  [Recurse]  If  there  is  such  an  implication  in  I  then  return 

U  All-models(r'  U  {Li}) 

1  <  X  <  n 

Note  that  if  there  are  no  complex  implications  in  I  then  All- models  ({C}) 
is  either  empty  or  contains  exactly  one  model  which  is  derived  by  computing  the 
simple  closure  T'  of  the  singleton  set  {C}. 

The  above  procedure  can  be  made  more  efficient  in  several  ways.  The  search  for 
a  complex  implication  in  step  3  can  be  optimized  to  avoid  searching  all  implications 
in  I.  Also,  the  set  of  literals  T  used  in  this  procedure  can  be  represented  with  a 
hash  table  so  that  membership  tests  take  unit  time  on  average.  The  details  of  these 
optimizations  are  left  to  the  reader.  It  is  important  to  note,  however,  that  this 
computation  is  only  exponential  in  the  number  of  complex  implications  of  the  form 
specified  in  step  3.  All  that  remains  is  to  show  that  this  algorithm  produces  all  the 
possible  models. 

Lemma  III.  Every  element  of  All-Models({C})  is  a  model  of  I  which  con¬ 
tains  C.  Furthermore  every  model  of  /  which  contains  C  also  contains  (as  a 

subset)  some  element  of  All-Models({C}). 

The  above  lemma  implies  that  the  intersection  of  the  models  in  All-Mod- 
els({C})  is  equal  to  the  intersection  of  all  models  of  I  which  contain  C.  In  other 
words  this  intersection  is  the  set  of  generalizations  of  C  under  I.  The  proof  of  this 
lemma  is  presented  in  the  appendix. 

If  the  above  procedure  returns  the  empty  set  when  applied  to  the  singleton  set 
{C}  then  there  are  no  models  of  I  which  contain  C  and  thus  I  implies  (mot  C)  so 
C  is  not  instantiable.  If  the  procedure  returns  a  set  of  models  then  the  intersection 
of  those  models  is  the  set  of  class  symbols  which  are  generalizations  of  C.  Given 
the  set  of  symbols  which  are  generalizations  of  C  one  can  can  consider  a  hypothet¬ 
ical  instantiation  y  of  C.  This  hypothetical  instantiation  will  satisfy  every  simple 
implication  in  /,  but  there  might  be  some  complex  implication  which  is  violated  by 
y.  If  some  implication  is  violated  by  y  then  C  is  uninstantiable.  On  the  other  hand 
if  every  implication  in  /  is  satisfied  by  y  then  C  is  instantiable  and  we  can  compute 
the  set  of  information  bearing  class  expressions  that  are  true  of  the  hypothetical 
instantiation  y. 
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4.  Possible  Extensions 

For  any  predicate  C  one  would  like  to  be  able  to  specify  the  behavior  of  func¬ 
tions  and  methods  when  applied  to  objects  that  satisfy  the  predicate  C.  This  can 
be  done  in  two  different  ways:  one  can  write  explicit  conditionals  in  the  code  for 
methods  and  functions  or,  for  certain  predicates,  one  can  represent  the  predicate 
C  as  a  class  and  define  methods  for  that  class.  Boolean  classes  expand  the  set  of 
predicates  which  can  be  represented  as  classes.  It  might  be  possible  to  extend  the 
class  vocabulary  even  further  so  that  other  predicates  can  be  represented  as  classes. 
For  example  one  might  want  to  define  the  class  of  ships  whose  current  momentum  is 
greater  than  1000,  or  the  class  of  missiles  that  are  within  ten  miles  of  their  targets. 

Predicates  can  be  divided  into  three  groups.  First  there  are  instance  ignoring 
predicates.  A  predicate  C  is  instance  ignoring  if  the  truth  of  C  on  an  object  i 
depends  only  on  the  class  of  x  (the  class  that  x  is  an  instantiation  of)  and  not 
on  any  particular  properties  of  the  instance  x.  All  boolean  class  expressions  are 
instance  ignoring.  Second  there  are  instance  sensitive  time  invariant  predicates.  A 
predicate  C  is  time  invariant  if  the  truth  of  C  on  an  object  i  does  not  change  over 
time.  Third,  there  are  time  varying  predicates.  A  predicate  C  is  time  varying  if 
the  truth  of  C  on  an  object  x  changes  over  time.  It  is  progressively  more  difficult  to 
extend  the  class  vocabulary  to  these  three  types  of  predicates,  because  inheritance 
information  is  available  respectively  at  compile  time,  at  object  creation  time  and  at 
run  time. 

As  an  example  of  an  instance  sensitive  predicate  that  is  time  invariant  consider 
a  class  COUPLING-CAPACITOR  that  contains  those  capacitor  objects  whose  capaci¬ 
tance  is  above  a  given  threshold.  We  assume  that  the  capacitance  of  a  capacitor 
is  given  at  object  creation  time  and  never  changes.  Whenever  a  capacitor  object  is 
created  one  could  determine  whether  or  not  it  is  an  instance  of  COUPLING-CAPACI¬ 
TOR. 


Time  varying  predicates  are  quite  common  and  one  could  imagine  specifying 
methods  in  terms  of  classes  defined  by  time  varying  predicates.  It  should  be  possible 
to  implement  time  varying  classes  by  automatically  converting  the  behavioral  speci¬ 
fications  associated  with  classes  into  run-time  conditionals  in  the  code  for  methods. 

The  potential  benefits  and  pitfalls  of  extending  the  class  vocabulary  to  more 
general  kinds  of  predicates  are  not  yet  clear;  we  have  not  investigated  the  uninstan- 
tiable  class  problem  or  the  modularity  breakdown  problem  for  instance  sensitive  or 
time  varying  classes.  It  seems  likely  that  any  implementation  of  instance  sensitive  or 
time  varying  classes  would  involve  in-line  conditional  tests  in  the  code  for  methods. 
Thus  it  is  not  clear  that  there  is  any  advantage  in  representing  these  predicates  as 
classes  as  opposed  to  using  these  predicate  in  traditional  in-line  conditionals. 
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;  5.  Appendix:  The  Proof  of  Lemma  III 

» 

I 

I  Consider  the  following  procedure  given  in  the  third  section  of  this  paper. 

Function:  All- Models (T)  takes  a  set  of  literals  and  produces  a  set  of  models. 

I 

1.  [Initialization]  Let  T'  be  the  simple  closure  of  T  with  respect  to  I. 

\ 

\ 

I  2.  [Detect  inconsistency]  If  T*  is  inconsistent,  i.e.  if  there  is  some  symbol  C  in 

T'  such  that  (:not  C)  is  also  in  T,  then  return  the  empty  set  (there  are  no 
models  of  T). 

3.  [Choose  complex  implication]  Let  us  assume  that 

(rimplies  C  (:or  Li  L\...Ln)) 

is  a  complex  implication  in  I  such  that  C  is  in  T'  but  none  of  the  literals 
Li,L2,...Ln  are  in  T'.  If  there  is  no  such  implication  in  /  then  return  {M} 
where  M  is  the  set  of  class  symbols  in  T' . 

4.  [Recurse]  If  there  is  such  an  implication  in  I  then  return 

U  All-model8(r  U  {Li}) 

I  <  i  <  n 

Note  that  a  recursive  call  in  step  4  can  return  the  empty  set  in  which  case 
that  recursive  call  does  not  contribute  any  models  and  has  no  effect  on  the  result. 
A  recursive  call  returns  the  empty  set  if  the  set  of  literals  passed  to  that  call  is 
inconsistent  with  the  inheritance  specification  I. 

We  wish  to  prove  the  following  lemma: 

Lemma  III. 

(a)  Every  element  of  All-Model8({C})  is  a  model  of  I  which  contains  C. 

(b)  Every  model  of  I  which  contains  C  also  contains  (as  a  subset)  some  element 
of  All-Model8({C}). 

To  prove  part  (a)  let  Af  be  a  model,  M  €  All-Model8({C})  Clearly  M  contains 
C .  To  show  that  M  is  a  model  of  7  note  that  M  must  have  been  returned  at  step 
3  of  some  invocation  of  the  procedure.  At  step  3  of  the  procedure  there  exists  a 
consistent  set  of  literals  T'  such  that  M  is  the  set  of  class  symbols  in  T'  and  for  every 
(simple  or  complex)  implication  in  I  of  the  form  (:implie8  C  (:or  Li  Lj  ...  //„)), 
if  C  is  in  T'  then  some  Li  is  in  T'.  To  show  that  M  is  a  model  of  I  consider  an 
implication  of  the  form  (zimplies  C'  (:or  L\  L^-.-Ln))^  We  must  show  that  if 
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C  is  in  M  then  some  L,-  is  true  in  M.  If  C'  is  in  M  then  C'  is  in  T'.  But  this 
implies  that  T'  contains  some  Li.  Now  if  is  a  positive  literal  then  it  is  also 
contained  in  M  and  we  are  done.  On  the  other  hand  if  L,-  is  a  negative  literal  of 
the  form  (:not  C")  then  since  T'  is  consistent  C"  is  not  in  T'  and  thus  not  in  M 
so  (:not  C")  is  true  in  M. 

Now  we  must  prove  that  every  model  of  I  which  contains  C  also  contains  (as 
a  subset)  some  element  of  All-Model8({C'}).  This  is  proven  via  a  more  general 
induction  hypothesis  on  the  function  All-Models. 

Definition;  Let  T  be  any  set  of  literals  and  let  I  be  any  inheritance  specifica¬ 
tion  in  conjunctive  normal  form.  A  model  M  of  T  (relative  to  /)  is  a  model  of 

I  such  that  every  literal  in  T  is  true  in  Af . 

Note  that  a  model  M  of  a  set  of  literals  T  can  contain  class  symbols  which 
do  not  appear  in  T.  In  the  extreme  cause  M  might  be  infinite  while  T  is  finite. 
We  will  show  that,  in  general,  every  model  of  I  and  T  contains  (as  a  subset)  some 
member  of  All-Models(T).  In  particular  this  implies  that  every  model  of  I  and 
{C}  (i.e.  every  model  of  /  which  contains  C)  contains  (as  a  subset)  some  member 
of  All-Models({C}). 

To  prove  the  general  induction  hypothesis  we  first  note  that  the  function  All- 
Models  must  always  terminate  because  the  number  of  literals  increases  in  every 
recursive  call  and  if  the  number  of  literals  in  T  becomes  larger  than  the  number 
of  class  symbols  appearing  in  I  then  T  must  be  inconsistent  and  the  procedure 
terminates. 

Now  we  assume  that  the  induction  hypothesis  holds  for  recvirsive  calls  and  we 
show  that  it  must  then  hold  for  the  top  level  call.  First  note  that  if  T'  is  the  simple 
closure  of  T  every  model  of  T  (relative  to  7)  is  also  a  model  of  T' .  Thus  if  T'  is 
inconsistent  then  there  are  no  models  of  T  and  the  lemma  holds.  Furthermore, 
every  model  of  T  is  also  a  model  of  T’  and  therefore  must  contain  (as  a  subset) 
all  of  the  positive  literals  in  T'.  Now  suppose  the  procedure  exits  in  step  3  by 
returning  the  positive  literals  in  T'.  Since  every  model  of  T'  must  contain  (as 
a  subset)  the  positive  literals  in  T'  the  lemma  holds.  Finally  suppose  that  the 
procedure  returns  the  union  computed  in  step  4.  Let  Af  be  any  model  of  I  and  T 
and  let  (;implie8  C  (;or  Lj  Lx  ...£„))  be  the  implication  found  in  step  3.  Since 
T'  contains  C,  the  model  M  must  also  contain  C.  Furthermore,  since  by  definition 
Af  is  a  model  of  7,  some  literal  L*  must  be  true  in  Af.  This  implies  that  Af  is 
a  model  of  T'  U  {L,}  (relative  to  7)  for  some  Li  in  the  implication.  But  we  have 
assumed  that  the  induction  hypothesis  holds  for  recursive  calls  and  so  M  contains 
(as  a  subset)  some  member  M'  of  All-Models (T'D  {Li}).  But  Af'  is  a  member  of 
the  union  computed  at  step  4  so  the  lemma  holds. 
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